Conventional network-based communication systems include systems configured to operate in accordance with well-known synchronous transport standards, such as the synchronous optical network (SONET) and synchronous digital hierarchy (SDH) standards.
The SONET standard was developed by the Exchange Carriers Standards Association (ECSA) for the American National Standards Institute (ANSI), and is described in the document ANSI T1.105-1988, entitled “American National Standard for Telecommunications—Digital Hierarchy Optical Interface Rates and Formats Specification” (September 1988), which is incorporated by reference herein. SDH is a corresponding standard developed by the International Telecommunication Union (ITU), set forth in ITU standards documents G.707 and G.708, which are incorporated by reference herein.
The basic unit of transmission in the SONET standard is referred to as a synchronous transport signal level-1 (STS-1). It has a serial transmission rate of 51.84 Megabits per second (Mbps).
Synchronous transport signals at higher levels may be concatenated or channelized. For example, an intermediate unit of transmission in the SONET standard is referred to as synchronous transport signal level-3, concatenated (STS-3c). It has a serial transmission rate of 155.52 Mbps. The corresponding unit in the SDH standard is referred to as STM-1. In a concatenated synchronous transport signal, the entire payload is available as a single channel. A channelized signal, by way of contrast, is divided into multiple channels each having a fixed rate. For example, the channelized counterpart to the concatenated STS-3c signal is denoted STS-3. STS-3 is a channelized signal that comprises three separate STS-1 signals each at 51.84 Mbps.
A given STS-3c or STM-1 signal is organized in frames having a duration of 125 microseconds, each of which may be viewed as comprising nine rows by 270 columns of bytes, for a total frame capacity of 2,430 bytes per frame. The first nine bytes of each row comprise transport overhead (TOH), while the remaining 261 bytes of each row are referred to as a synchronous payload envelope (SPE). Synchronous transport via SONET or SDH generally involves a hierarchical arrangement in which an end-to-end path may comprise multiple lines with each line comprising multiple sections.
The TOH includes section overhead (SOH), pointer information, and line overhead (LOH). The SPE includes path overhead (POH) comprising a single column of bytes. The SOH includes a section trace byte J0 that is used to support continuity testing between transmitting and receiving devices of a given section within a particular line and path. The J0 byte may be used to transmit a one-byte string, a 16-byte string or a 64-byte string. The POH includes a path trace byte J1 that is used to support continuity testing between transmitting and receiving devices of a given path. Like the J0 byte, the J1 byte may also be used to transmit a one-byte string, a 16-byte string or a 64-byte string. Pointer bytes H1 and H2 in the TOH may be used to indicate the position of the POH column in the SPE. The strings transmitted using the J0 or J1 bytes are also referred to herein as “message sequences” or simply “messages.”
Additional details regarding SONET/SDH signal and frame formats can be found in the above-cited documents.
In conventional SONET or SDH network-based communication systems, synchronous transport signals like STS-3c or STM-1 are mapped to or from corresponding higher-rate optical signals such as a SONET OC-12 signal or an SDH STM-4 signal. An OC-12 optical signal carries four STS-3c signals, and thus has a rate of 622.08 Mbps. The SDH counterpart to the OC-12 signal is the STM-4 signal, which carries four STM-1 signals, and thus also has a rate of 622.08 Mbps. The mapping of these and other synchronous transport signals to or from higher-rate optical signals generally occurs in a physical layer device commonly referred to as a mapper, which may be used to implement an add-drop multiplexer (ADM) or other node of a SONET or SDH communication system.
Such a mapper typically interacts with a link layer processor. A link layer processor is one example of what is more generally referred to herein as a link layer device, where the term “link layer” generally denotes a switching function layer. Another example of a link layer device is a field programmable gate array (FPGA). These and other link layer devices can be used to implement processing associated with various packet-based protocols, such as Internet Protocol (IP) and Asynchronous Transfer Mode (ATM), as well as other protocols, such as Fiber Distributed Data Interface (FDDI). A given mapper or link layer device is often implemented in the form of an integrated circuit.
The particular formats used for messages carried by the J0 and J1 bytes of a SONET/SDH synchronous transport signal can vary depending upon the operating mode of the transmitting device. For example, in a SONET framing mode of operation with a frame synchronization flag, the transmitting device will automatically pad a given user-entered string to 62 bytes using ASCII NULL characters and then add <CR> and <LF> characters, given by 0D and 0A, respectively, in hexadecimal notation, for a total of 64 bytes. In the corresponding SDH framing mode with a frame synchronization flag, the most significant bit (MSB) of the first byte of a J0 or J1 message is set to a logic “1” value.
There are also SONET and SDH framing modes that do not utilize a frame synchronization flag. In such modes, there is no particular head or tail for the message sequence, and it can be captured in any phase since it appears circularly. This message format is required in the Multiplex Section Shared Protection Ring (MS-SPRING) arrangement described in ITU-T standards document G.841, which is incorporated by reference herein.
As another example, if there is no particular user-entered string to be transmitted using the J1 byte, the 64-byte string that is transmitted is set to all zeros using 64 consecutive ASCII NULL characters.
These and other variations in J0/J1 message formats can create problems for the receiving device. For example, the receiving device may have to negotiate with the transmitting device to set the appropriate operating mode in advance. This makes it difficult to alter existing connections “on the fly,” and to build new connections. Also, it is difficult to configure a given device to support multiple message formats such as those described above without significantly increasing the hardware costs associated with the device.
Accordingly, a need exists for an improved approach to monitoring of received information that can accommodate multiple message formats at low cost and without the need for advance negotiation between transmitting and receiving devices.